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Bill 

1. Talking with Terry recently, I learned that the RFP for the 
SAFE terminals may go out shortly. I am concerned. There are a 
number of serious questions that I have about the Delta Data 7260 
that lead me to wonder whether we are ready to make this long-term, 
expensive commitment. 

Although the terminal concept appears to be right-on with 
respect to our needs, the development seems to require a far greater 
investment than was anticipated and duplicates mature technology now 
emerging in the private sector. The imminent SAFE procurement 
appears to lock us in to a specific terminal, a unique terminal 
protocol, and a unique allocation of functions between host systems 
and terminals for probably the next 10 years or so. This uniqueness 
appears to me to commit the Agency to the development of all the 
needed terminal functions. I am concerned that that is a far bigger 
investment than we anticipated and of doubtful affordability. Even 
if we could afford it, the current status and recent history 
indicate that we are likely to end up having an all-up capability 
much later than we would using commercially available equipment, 
modified to fit our environment. 

2. The 7260 is a two-sided, flexible configuration system, 
with a mother board that can accept additional cards to perform a 
variety of functions. It is thus expandable to perform a wide 
variety of processing and interface functions. 

The version to go into BLOCK I of the SAFE (234 terminals) 
seems to be a "bare bones" version. As such, it is relatively 
economical — slightly less than $6K per unit, excluding RDT&E. While 
this cost looks quite attractive relative to the functions it 
provides, it is balanced by the rather high price of add-ons that 
are almost certain to be procurred, e.g. , $6K for a dual floppies 
system needed to support most independent processing operations. I 
suspect that an all-up 7260 is likely to gross out at about $20K, 
and extensive use of a retrofitting approach would increase that. 
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3. Specific questions that I have include the following: 

• A unique OS was developed for the terminal, rather than 
applying a standard microcomputer OS like CP/M. The 
result is that the great community of applications 
packages and languages hosted by such a common 

OS — including word processing (WP) , graphics, and 
compiled HOLs like COBOL, FORTRAN, and PASCAL — cannot be 
applied. We have to develop any such packages users 
want, as well as application packages such as statistical 
analysis and linear programming packages. 

• A unique form of BASIC has been developed for the 7250. 

It has some special primitives that are attractive for 
our environment, but has been described by one trial user 
as "arcane." It appears to me that we are unnecessarily 
committing ourselves to the support of a language. 

• Although graphic symbols and pictures are included, a 
graphics capability will not be immediately provided. I 
question very strongly fielding a smart terminal that 
does not have a graphics capability. A position that 
such a capability can be added later, if needed, seems 
very risky to me, and again commits us to expensive, 
unique in-house developments duplicating what is commonly 
available in the commercial arena. From what I can see, 

a graphics capability is needed now and should be in the 
initial version of any procured terminal. (The fact that 
users may not have stressed such a capability two years 
ago is irrelevant. NPIC, for one, needs a graphics 
capability now. I suspect NFAC does also.) 

• Of the 64K of core memory on the processing side, all but 
12K has been consumed by operational software. Since 12K 
is quite lfmited, and generally inadequate, there is talk 
about adding another 128K to the processing side. This 
would involve further RD&E investment for a new card, 
however, and modifications to the OS, of unknown scope. 

• It was required that the 7260 emulate the DD 5000 in 
hardware. I don't know how readily modifiable this is, 
but it seems to me a modifiable emulation is needed. 

This would permit us to modify protocol to another 
standard in the future, should we wish, avoiding having 
to write off the terminals prematurely because of a 
system reconfiguration. 

4. In thinking about alternatives and the realities of our 

environment — like meeting our terminal GFE Schedule to | |on 2.5X1 

SAFE — there are a number of factors to consider. I believe that: 
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• The immediate terminal application will be for WP, much 
of it not under SAFE, and analyst file manipulations, 
both under VM and SAFE with its SUfc. A processing 
capability is not needed in the Block I SAFE. 

9 There is a need within the near term for both BASIC 
programming support and graphics. These two functions 
require a full system capability, i.e., a special card 
and dual floppies. 

• The technology trend in large organizations is to provide 
distributed processing. I think that need can be met 
over the next five to ten years with a smart terminal 
configured to support compiled HOL processing, graphics, 
and numerous standard applications packages. If we do 
not meet the distributed processing need with smart 
terminal processors, I fear we will be forced into much 
more expensive and managerially difficult solutions 
involving distributed minis. 

The consequence of these factors is that a mix of terminal 
capabilities is a feasible and more economical solution than buying' 
all in the most complete configuration needed. The flexible 
approach is the SAFE plan, with some level of currently unplanned 
retrofitting to develop the needed, more sophisticated capabilities. 
The terminals could all be from one source, as planned by SAFE, or 
from more than one, as long as they are functionally compatible 
(including protocol). The only problem associated with different 
sources" of terminals that I see is duplication investment in 
functionalities and protocols to fit our environment. I do not 
believe that these are likely to be significant as compared to the 
benefit of being able to piggy-back available technology, as long as 
these are only a limited number of different sources. 


Bob 
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